Object-oriented DBMSs (database management systems) provide persistent storage for programming language objects, and they support storage of virtually any data structure in a programming language. In contrast, traditional record-structured DBMSs require embedded database language (e.g., SQL) statements or procedure calls to copy data back and forth between database and programming language representations, and they only support storage of records. Some new products allow traditional record-oriented databases to automatically be mapped to programming language objects, thus providing the same programmer's view as an object-oriented DBMS. The present invention is an innovative implementation technqiue for these object-relational mappings and also for object-oriented DBMSs. For our purposes, we will use the latter term for both.
An attractive aspect of object-oriented databases is that the computer programs used to manipulate such databases are much easier to understand than traditional database access programs. A much more important advantage of object-oriented databases is that “static data type enforcement” can be applied to the computer programs that access the database. This means that the compiler of such programs can ensure that all data stored in a particular database field matches the data type defined for that field. Thus, a program that tries to put an integer into an employee's name field would be rejected by the compiler in an object-oriented system.
Unfortunately, writing object-oriented programs to access data stored on disk or other secondary memory in a DBMS (database management system) is more difficult than it might appear at first glance. While it is reasonably straightforward to write object class methods that translate accesses to an object field into database queries, writing the code to consistently determine when data needs to be read from the database and when data needs to be written back into the database is somewhat tricky because of the ways in which references to objects (i.e., references in objects to other objects) can be used. For instance, it is important not to inadvertently create two objects in memory that represent the same database object.
For the purposes of this document, the terms “memory” and “main memory” shall be defined to mean the random access memory or primary memory of a computer system, while the terms “secondary memory” and “persistent storage” shall mean disk memory or other form of storage that retains data on a more persistent or longer term basis than main memory.
It is a goal of the present program to enable programmers to write object-oriented database utilization programs as though they were simply dealing with database objects in main memory, without having to concern themselves with the mechanisms for reading and writing data from and to the actual persistent storage database.
More particularly, it is a goal of the present invention to provide a system and method for “post processing” a compiled object-oriented database program so as to automatically insert additional code required to copy data from the database into objects in memory, and to copy new and modified data from objects in memory into the database, at the appropriate times. In this way, programmers can write object-oriented database programs in which objects representing persistently stored data are handled, for purposes of the initial source code program, no differently than objects storing non-persistent data.